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On 

Abstract 

Serious thinking about the computational aspects of situation theory is 
I't ^ just starting. There have been some recent proposals in this direction (viz. 

PROSIT and ASTL), with varying degrees of divergence from the ontology 
^-H of the theory. We believe that a programming environment incorporating 

bona fide situation-theoretic constructs is needed and describe our very 
CN recent BABY-SIT implementation. A detailed critical account of PROSIT 

and ASTL is also offered in order to compare our system with these pio- 

neering and infiuential frameworks. 

o 

OS 

1 Introduction 



Situation theory has been devised to develop a unified mathematical theory of 
meaning and information content and to clarify and resolve various long-standing 
problems in the study of language, information, logic, philosophy, and the mind. 
The original theory was due to Jon Barwise and John Perry [6]. The theory has 
matured over the last decade [12] and various versions of it have been applied to 
a number of linguistic issues, resulting in what is commonly known as situation 
semantics [2, 3, 5, 11, 15, 16, 18, 25]. Situation semantics aims at the construction 
of a mathematically rigorous theory of meaning, and the application of such a 
theory to natural language. 

The mathematical foundations of the theory are based on intuitions basically 
coming from set theory and logic [1, 3, 11, 12]. One of the distinguishing char- 
acteristics of situation theory vis-a-vis another influential semantic theory in the 
logical tradition [13] is that information content is context-dependent. 
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While not much work has been done to construct a computational framework 
based on situation theory, there have been some attempts to investigate this 
[8, 9, 16, 23]. These have incorporated only some of the original features of the 
theory; the remaining features were omitted for the sake of achieving particular 
goals. This has caused conceptual and philosophical divergence from the ontology 
of the theory. Recent studies [26, 27, 28, 29] have tried to avoid this pitfall 
by simply sticking to the essentials of the theory and adopting the ontological 
features which were first put forward by Barwise and Perry [6] and then refined 
by Devlin [12]. 

In this paper, we review the existing approaches towards a computational ac- 
count of situation theory; this may serve as a guideline for researchers who aim 
at constructing programming systems permitting the use of situation-theoretic 
constructs. We briefiy review situation theory and situation semantics in Sec- 
tions 2 and 3. In Section 4, we briefiy explain why situations should be used in 
natural language processing, and in knowledge representation for semantic inter- 
pretation and reasoning. The existing computational accounts based on situation 
theory are examined in Section 5. Finally, we present our concluding remarks in 
Section 6. 

2 Situation Theory 

Individuals, properties, relations, spatio-temporal locations, and situations are 
basic constructs of situation theory. The world is viewed as a collection of objects, 
sets of objects, properties, and relations. Individuals are conceived as invariants; 
having properties and standing in relations they persist in time and space. All 
individuals, including spatio-temporal locations, have properties. 

Infons [12] are discrete items of information and situations are first-class ob- 
jects which describe parts of the real world. Infons are denoted as ^ i?, ai, . . . , 
a„, z ^ where R is an n-place relation, objects appropriate for the 

respective argument places of i?, and i is the polarity (0 or 1). Situations are 
intensional objects. For this reason, abstract situations are proposed to be their 
counterparts amenable to mathematical manipulation. An abstract situation is 
defined as a set-theoretic construct. Given a real situation s, the set {cr | s |= cr}, 
where a is an infon, is the corresponding abstract situation. Here, s is said to 
support cr (denoted as s |= cr) just in case a is true of s. Otherwise, s ^ cr. In 
case of abstract situations, the supports relation reduces to set-inclusion. 

Suppose Alice was eating ice cream yesterday at home and she is also eating 
ice cream now at home. Both of these situations share the same constituent 
sequence ^eats, Alice, ice cream^. These two events, occurring at the same 
location but at different times, have the same situation type s. Situation types 
are partial functions from relations and objects to and 1. The situation type s 
in our example assigns 1 to the constituent sequence ^eats, Alice, ice cream^. 
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Situation types can be more general. For example, a situation type in which 
someone is eating something at home 'contains' the situation in which Alice is 
eating ice cream at home. Suppose Alice is not present in the room where this 
paper is being written. Then, "Alice is eating ice cream" is not part of our 
situation s and hence gets no truth value in s. Thus, situation theory allows 
partiality [16]. 

Situations in which a sequence is assigned both truth values are incoherent. 
For instance, a situation s is incoherent if ^has, Alice, A'v', 0^ G s and ^has, 
Alice, A'v", 1^ G s. This is a situation in which Alice has the A'v* and she does 
not have the A'v* in a card game. There cannot be a real situation s validating 
this. Nevertheless, the constituent sequence ^has, Alice, A'v'^ may be assigned 
these truth values for spatio-temporally distinct situation types (say, s and s'). 

Allowing partiality has the advantage of distinguishing between logically equiv- 
alent statements. For example, the statements "Bob is angry" and "Bob is angry 
and Bob is shouting or Bob is not shouting" are logically equivalent in the clas- 
sical sense. In situation semantics, these two sentences will not have the same 
interpretation. A situation s describing the situation in which Bob is only angry 
will not contain any sequence about Bob's shouting, i.e., s will be 'silent' on Bob's 
shouting. However, another situation s' obtained as the union of two situations 
(Bob is angry and Bob is shouting; Bob is angry and Bob is not shouting) will 
contain a sequence about Bob's shouting. 

A scheme of individuation^ a way of carving the world into uniformities, is an 
essential aspect of situation theory. The notions of individual, relation, spatial 
and temporal location depend upon this schema of individuation. In other words, 
the basic constituents of the theory are determined by the agent's schema of 
individuation. Formal representation of these uniformities yields what is known 
as types. 

Situation theory provides a collection of basic types that can be used for 
individuating or discriminating uniformities of the real world. There are nine 
basic types: temporal location (TIM), spatial location (LOG), individual (IND), 
n-place relation (RFL"), situation (SIT), infon (INF), type (TYP), parameter 
(PAR), and polarity (POL). 

If R is an n-place relation and ai,...,am {m < n) are objects appropri- 
ate for the argument places of i?, and if the filling of these argument 
places is sufficient to satisfy the minimality conditions for i?, then for i G {0, 1}, 
^i?, ai, is a well-defined infon. Minimality conditions for a particular 
relation are the collection of conditions that determine which particular groups 
of argument roles need to be filled in order to produce an infon. If m < n, the 
infon is said to be unsaturated; if m = n it is saturated. 

Abstraction can be captured in a primitive level by allowing parameters in in- 
fons. Parameters are generalizations over classes of non-parametric objects (e.g., 
individuals, spatial locations). Parameters of a parametric object can be associ- 
ated with objects which, if they were to replace the parameters, would yield one 
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of the objects in the class that parametric object abstracts over. The parametric 
objects actually define types of objects in that class. Hence, allowing parame- 
ters in infons results in parametric infons. For example, ^sees, i, Alice, 1^ and 
^sees, i, y, 1^ are parametric infons where x and y stand for individuals. These 
infons are said to be parametric on the first, and the first and second argument 
roles of the relation sees, respectively. 

Anchoring (binding) parameters of an infon to real objects yields parameter- 
free infons. For example, in ^goes, i, Chicago, 1^ if an anchoring function 
/ anchors x to the individual John, we obtain the parameter-free infon ^goes, 
John, Chicago, 1^. 

Parameters can be restricted so that they represent finer uniformities. Given 
a parameter x and a set of infons /, x^I restricts the class of objects that can 
be anchored to x only to the ones for which / hold in the 'world' situation. This 
process is known as parameter restriction. 

Complex object types can be defined over some intial situation. Given a 
situation s, a parameter i, and a set of infons (involving x) /, one can define 
[i I s 1= /] to denote the type (class) of all objects for which the conditions 
imposed by / hold in s. This process of obtaining a type from a parameter i, a 
situation s, and a set / of infons, is referred to as type-abstraction, x is called 
the abstraction parameter while s is called the grounding situation. 

A situation s' is part-of another situation s (denoted by s' ^ s) just in case 
(V(t)[s' 1= cr =^ s \= The part-of relation between situations is anti-symmetric, 
refiexive, and transitive, and consequently provides a partial-ordering of the sit- 
uations. 

In situation theory, information fiow is made possible by a network of abstract 
'links' between high-order uniformities, viz. situation types. These links are called 
constraints. Barwise and Perry identify three forms of constraints [6]. Wecessarj 
constraints are those by which one can define or name things, e.g., "Fvery dog is 
a mammal." Nomic constraints are patterns that are usually called natural laws, 
e.g., "Blocks fall if not supported." Conventional constraints are those arising out 
of explicit or implicit conventions that hold within a community of living beings, 
e.g., "The first day of the month is the pay day." They are neither nomic nor 
necessary, i.e., they can be violated. All types of constraints can be conditional 
and unconditional. Conditional constraints can be applied to situations that fulfill 
some condition while unconditional constraints can be applied to all situations. 

3 Situation Semantics 

According to situation semantics, meanings of expressions reside in systematic 
relations between different types of situations. They can be identified with re- 
lations on discourse situations J, (speaker) connections c, the utterance (p itself, 
and the described situation e. Some public facts about (p (such as its speaker and 
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time of utterance) are determined by the discourse situations. The ties of the 
mental states of the speaker and the hearer with the world constitute c. A dis- 
course situation involves the expression uttered, its speaker, the spatio-temporal 
location of the utterance, and the addressee(s). Each of these defines a linguistic 
role (the role of the speaker, the role of the addressee, and so on). 

The utterance of an expression 'constrains' the world in a certain way, de- 
pending on how the roles for discourse situations, connections, and described 
situations are occupied. For example, "I am crying" describes a three-place re- 
lation |I am crying] on the utterance situation (the discourse situation and the 
connections) u and the described situation e. This defines a meaning relation: 

J, c|I am crying] e. 

Given a discourse situation J, connections c, and a course of events e, this 
relation holds just in case there is a location and a speaker such that is 
speaking at Z^, and in e, is crying at l^. 

In interpreting the utterance of an expression (p in a context u (J, c), there is a 
fiow of information, partly from the linguistic form encoded in (p and partly from 
contextual factors provided by the utterance situation u. These are combined to 
form a set of constraints (not uniquely determined) on the described situation e: 
given u and an utterance of in u, there will be several situations e that satisfy 
the constraints imposed. While the meaning of an utterance of (p and hence 
its interpretation are infiuenced by other factors such as stress, modality, and 
intonation [16], the situation in which p is uttered and the situation e described 
by this utterance seem to play the most infiuential roles. For this reason, the 
meaning of an utterance is essentially taken to be a relation defined over p^ u, 
and e. This approach towards identifying linguistic meaning is essentially what 
Barwise and Perry call the Relation Theory of Meaning [6]. 

Situation semantics makes simple assumptions about the way natural lan- 
guage works. Primary among them is the assumption that language is used 
to convey information about the world (the so-called external significance of lan- 
guage). Fven when two sentences have the same interpretation, i.e., they describe 
the same situation, they can carry different information. 

Classical approaches to semantics underestimate the role played by context- 
dependence; they ignore pragmatic factors such as intentions and circumstances of 
the individuals involved in the communicative process. But, indexicals, demon- 
stratives, tenses, and other linguistic devices rely heavily on context for their 
interpretation. Context-dependence is an essential hypothesis of situation se- 
mantics. A given sentence can be used over and over again in different situations 
to say different things (the so-called efEciency of language). Its interpretation, 
i.e., the class of situations described by the sentence, is therefore subordinate 
on the situation in which the sentence is used. This context-providing situation, 
discourse situation^ is the speech situation, including the speaker, the addressee, 
the time and place of the utterance, and the expression uttered. Since speakers 
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are always in different situations, having different causal connections to the world 
and different information, the information conveyed by an utterance will be rel- 
ative to its speaker and hearer (the so-called perspectival relativity of language) 
[6]. 

Besides discourse situations, the interpretation of an utterance depends on 
the speaker's connections with objects, properties, times and places, and on the 
speaker's ability to exploit information about one situation to obtain information 
about another. Therefore, context supports not only facts about speakers, ad- 
dressees, etc. but also facts about the relations of discourse participants to other 
contextually relevant situations such as resource situations. Resource situations 
are contextually available and provide entities for reference and quantification. 

According to situation semantics, we use meaningful expressions to convey 
information not only about the external world but also about our minds (the 
so-called mental significance of language). Situation semantics differs from other 
approaches in that we do not, in attitude reports, describe our mind directly 
(by referring to states of mind, ideas, senses, thoughts, etc.) but indirectly (by 
referring to situations that are external). 

With these underlying assumptions and features, situation semantics provides 
a fundamental framework for a realistic model-theoretic semantics of natural lan- 
guage. The ideas emerging from research in situation semantics have been coa- 
lesced with well-developed linguistic theories such as lexical-functional grammar 
and led to rigorous formalisms [16]. On the other hand, situation semantics 
has been compared to other infiuential mathematical approaches to the theory 
of meaning, viz. Montague Grammar [10, 13, 24] and Discourse Representation 
Theory (DRT) [19]. 

4 Why Compute with Situations? 

A computational formulation of situation theory may generate interest among 
artificial intelligence and natural language processing researchers. The theory 
claims that its model theory is more amenable to a computationally tractable 
implementation than standard model theory (of predicate calculus) or Montague 
Grammar. This is due to the fact that situation theory emphasizes partiality 
whereas standard model theory is clearly holistic. 

From a natural language processing point of view, situation theory is in- 
teresting and relevant simply because the linguistic account of the theory (viz. 
situation semantics) handles various linguistic phenomena with a fiexibility that 
surpasses other proposals. It seems that indexicals, demonstratives, referential 
uses of definite descriptions, pronouns, tense markers, names, etc. all have tech- 
nical treatments in situation semantics that reach beyond available theoretical 
apparatuses. For example, the proposed mechanisms, as reported in [18], for 
dealing with quantification and anaphoric connections in Fnglish sentences are 
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all firmly grounded in situation semantics. The insistence of situation semantics 
on contextual interpretation makes the theory more compatible with speech act 
theory (and pragmatics in general) than other theories.^ 

5 Computational Frameworks 
5.1 PROSIT 

PROSIT (PROgramming in Situation Theory) is the pioneering work in this 
direction. PROSIT is a situation-theoretic programming language developed by 
Nakashima et al. [23]. It has been implemented in Common Lisp. 

PROSIT is tailored more for knowledge representation in general than for 
natural language processing. One can define situations and assert knowledge in 
particular situations. It is also possible to define relations between situations 
in the form of constraints. PROSIT's computational power is due to an ability 
to draw inferences via rules of inference. There is an inference engine similar 
to a Prolog interpreter. PROSIT offers a treatment of partial objects, such as 
situations and parameters. It can also deal with self-referential expressions [5]. 

One can assert facts that a situation will support. For example, if si supports 
the fact that Bob is a young person, this can be defined in the current situation 
s as: 

s: (!= si (young Bob)). 

Note that the syntax is similar to that of Lisp and the fact is in the form of 
a predicate. The supports relation, !=, is situated so that whether a situation 
supports a fact depends on where the query is made. 

In PROSIT, there exists a tree hierarchy, with the situation top at the root 
of the tree, top is the global situation and the 'owner' of all the other situations 
generated. One can traverse the 'situation tree' using the predicates in and out. 
Although it is possible to make queries from a situation about any other situation, 
the result will depend on where the query is made. If a situation sit 2 is defined 
in the current situation, say sitl, then sitl is said to be the owner of sit 2. 

The owner relation states that if ( ! = sit2 infon) holds in sitl, then infon 
holds in sit2, and conversely, if infon holds in sit2 then (!= sit2 infon) 
holds in sitl. So, in causes the interpreter to go to a specified situation which 
will be a part of the 'current situation' (the situation in which the predicate is 
called) and out causes the interpreter to go to the owner of the current situation. 

^Kamp's DRT may safely be considered as the only competition in this regard [19]. However, 
it should be noted that there are currently research efforts towards providing an 'integrated' 
account of situation semantics and DRT, as witnessed by Barwise and Cooper's recent work 
[4]. 
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Similar to the owner relation between situations there is the 'subchunk' rela- 
tion. It is denoted as (c< sitl sit 2), where sitl is a subchunk of sit 2, and 
conversely, sit 2 is a superchunk of sitl. When a situation, sitl, is asserted 
to be the subchunk of another situation, sit 2, it means that sitl is totally de- 
scribed by sit 2. A superchunk is like an owner except that out will always cause 
the interpreter to go to the owner, not to a superchunk. 

PROSIT has two more relations that can be defined between situations. These 
are the 'subtype' relation and the 'subsituation' relation. When the subtype 
relation (denoted by (-> sitl sit2)) is asserted, it causes the current situation 
to describe that sitl supports i for every infon i valid in sit 2 and that sitl 
respects every constraint that is respected by sit2, i.e., sit2 becomes a subtype 
of sitl. The subsituation relation is denoted as (s< sitl sit2) and is the same 
as (-> sitl sit2) except that only infons, but no constraints, are inherited. 
Both relations are transitive. 

One can define a 'default inheritance' relation between two situations. When 
a default inheritance relation (denoted by (d< sitl sit2)) is asserted, sitl 
inherits an infon i to sit 2 if and only if (no i) cannot be proved to hold in 
sit2. 

The fact that PROSIT permits situations as arguments to infons makes it 
possible to represent self-referential statements. Consider a card game where 
there are two players. John has the ace of spades and Mary has the queen of 
spades. When both players display their cards the following infons will be true: 

(!= sit (has John ace-of -spades) ) 

(!= sit (has Mary queen-of -spades) ) 
(!= sit (sees John sit)) 
(!= sit (sees Mary sit)) 

There is no notion of situation type in PROSIT. For this reason, one cannot 
represent abstractions over situations and specify relations between them without 
having to create situations and assert facts to them. 

It is possible to define a relation as an abstraction over parameters of an infon. 
A PROSIT expression of the form 

[ pari ■ ■ ■ paVn \ infon ] 

describes an abstraction and it can be applied to arguments: 

([ pari ■ ■ ■ paVn \ infon ] argi . . . argn) 

to yield infon' where infon' is the result of replacing each pari in infon with the 
corresponding argi. Therefore, abstraction in PROSIT does not yield an object 
type or situation type in the situation-theoretic sense. 

PROSIT allows definition of a special kind of infon which is called restricted 
infon. An expression of the form 

(" infonl infoni) 
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defines an infon where infon2 is tlie restriction of infonl. For exampie, 

i" (man P) (human P)) 

puts a restriction on tlie parameter P of tlie infon (man P) sucli tliat P must 
fulfill the relation human. Hence, a restriction specifies what relations hold of the 
parameters of the infon. This approach does not provide a mechanism equivalent 
to parameter restriction; rather it seems to offer a limited mechanism to specify 
appropriateness conditions for a given relation and a specific parameter. 

PROSIT has a constraint mechanism. Constraints can be specified using 
either of the three relations and <^=>. Constraints specified using =^ (re- 

spectively, are forward (respectively, backward) chaining constraints; the ones 
using <^=> are both backward- and forward- chaining constraints. Backward chain- 
ing constraints are of the form (<^ bead facti . . . factn). If all the facts are 
supported by the situation, then the head fact is supported by the same situa- 
tion. Forward chaining constraints are of the form (=^ fact taili . . . tailn). If fact is 
asserted to the situation, then all the tail facts are asserted to the same situation. 
Backward chaining constraints are activated at query-time while forward- chaining 
constraints are activated at assertion-time. By default, all the tail facts of an ac- 
tivated forward- chaining constraint are asserted to the situation, which may in 
turn activate other forward- chaining constraints recursively. 

For a constraint to be applicable to a situation, the situation must be declared 
to 'respect' the constraint. This is done by using the special relation respect. For 
example, to state that every man is human, one would write: 

s: (resp si (<= (human *X) (man *X))). 

This states that si respects the stated constraint and is made with respect to 
s. (*X denotes a variable.) Since assertions are situated, a situation will or will 
not respect a constraint depending on where the query is made. If we assert: 

s : ( ! = si (man Bob) ) , 

then PROSIT will affirmatively answer the query: 

s? ( != si (human Bob)) . 

Constraints in PROSIT are about local facts within a situation rather than 
about situation types. That is, the interpretation of constraints does not allow 
direct specification of constraints between situations, but only between infons 
within situations. 

Parameters, variables, and constants are used for representing entities in 
PROSIT. Variables, rather than parameters, are used to identify the indeter- 
minates in a constraint. Parameters might be used to refer to unknown objects 
in a constraint. Variables have a limited scope; they are local to the constraint in 
which they appear. Parameters, on the other hand, have global scope. Variables 
match any expression in the language and parameters be can equated to any 
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constant or parameter. 

PROSIT has been used to show how problems involving cooperation of mul- 
tiple agents can be studied, especially by combining reasoning about situations. 
In [22], Nakashima et al. demonstrate how the Conway paradox [3, pp. 201-220] 
can be solved. The agents involved in this problem use the common knowledge 
accumulated in a shared situation. This situation functions as a communication 
channel containing all information known to be commonly accessible. One agent's 
internal model of the other is represented by situations. Individual knowledge sit- 
uation plus the shared situation help an agent to solve the problem; also cf. [14] 
for further work on similar epistemic puzzles. 

5.2 ASTL 

Black's ASTL (A Situation Theoretic Language) is another programming lan- 
guage based on situation theory [8]. ASTL is aimed at natural language process- 
ing. One can define in ASTL constraints and rules of inference over the situations. 
An interpreter, a basic version of which is implemented in Common Lisp, passes 
over ASTL definitions and answers queries about the set of constraints and basic 
situations. 

ASTL allows individuals, relations, situations, parameters, and variables. 
These form the basic terms of the language. Complex terms are in the form 
of i-terms (to be defined shortly), situation types, and situations. Situations may 
contain facts which have those situations as arguments. Sentences in ASTL are 
constructed from terms and can be constraints, grammar rules, or word entries. 

The complex term i-term is simply an infon (re/, ar(/i, . . . , arg^ pol) where 
rel is a relation of arity n, argi is a term, and pol is either or 1. A situation 
type is given in the form [par \ condi. . . condn] where condi has the form par |= 
i-term. If situation SI supports the fact that Bob is a young person, this can be 
defined as: 

SI: [S I S 1= (young, bob, 1)] . 

The single colon indicates that SI supports the situation type on its right-hand 
side. The supports relation in ASTL is global rather than situated. Consequently, 
query answering is independent of the situation in which the query is issued. 

Constraints are actually backward-chaining constraints. Each constraint is of 
the form sHq : typeo <^ siti : typei, . . . ^sitn ■ type^ where siti is a situation or 
a variable, and typei is a situation type. If each szt^, 1 < z < n, supports the 
corresponding situation type, typci, then sHq supports typeo. For example, the 
constraint that every man is a human being can be written as follows: 

*S: [S I S 1= (human, *X,1)] <= *S: [S | S |= (man,*X,l)]. 

*S, *X are variables and S is a parameter. An interesting property of ASTL is 
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that constraints are global. Thus, a new situation of the appropriate type need 
not have a constraint explicitly added to it. Assume that SI, supporting the fact 
that Bob is a man, is asserted: 

SI: [S I S 1= (man, bob, 1)] . 

This together with the constraint above would give: 

SI: [S I S 1= (human, bob, 1)] . 

Grammar rules are another form of constraint. An example grammar rule 
describing the utterance of a sentence consisting of a noun phrase and verb phrase 
is 

*S: [S I S 1= (cat, S, sentence,!)] 

*NP: [S I S 1= (cat,S,nounphrase,l)] , 
*VP: [S I S 1= (cat,S,verbphrase,l)] 

where cat denotes the category of the construct, and — )• indicates that this is a 
grammar rule. The rule reads: "When there is a situation *NP of the given type 
and situation *VP of the given type, there is also a situation *S of the given type." 

As in PROSIT, variables in ASTL have scope only within the constraint they 
appear. They match any expression in the language unless they are declared to 
be of some specific situation type in the constraint. Hence, it is not possible 
to declare variables as well as parameters to be of other types such as individ- 
uals, relations, etc. Consequently, anchoring of parameters cannot be achieved 
appropriately in ASTL. 

The primary motivation underlying ASTL was to figure out a framework in 
which semantic theories such as situation semantics [3] and DRT [19] can be 
described and possibly compared. Such an attempt can be found in [7]. 

5.3 Situation Schemata 

Situation schemata have been introduced by Fenstad et al. [16] as a theoretical 
tool for extracting and displaying information relevant for semantic interpreta- 
tion from linguistic form. The boundaries of situation schemata are fiexible and 
depending on the underlying theory of grammar, are susceptible to amendment. 

A simple sentence (p has the situation schema shown in Figure 1(a). Here r 
can be anchored to a relation, and a and b to objects; i G {0,1} gives the polarity. 
LOG is a function which anchors the described fact relative to a discourse situation 
J, c. LOG will have the general format in Figure 1(b). IND.a is an indeterminate 
for a location, r denotes one of the basic structural relations on a relation set i?, 
and Iocq is another location indeterminate. The notation [ ]„ indicates repeated 
reference to the shared attribute value, IND.a. A partial function g anchors the 
location of SIT.(/j, viz. SIT. (/j. LOG, in the discourse situation J, c if 
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SIT.v^r 



IND 



IND.a 



REL 



r 



ARG.l a 



REL 



r 



ARG.2 b 



COND 



ARG.l [] 



a 



LOG 



ARG.2 locd 



POL 



POL 



(a) 



(b) 



Figure 1: (a) A prototype situation schema, (b) the general format of LOG in 



where /oq is the discourse location and c(r) is the relation on R given by the 
speaker's connection c. The situation schema corresponding to "Alice saw the 
cat" is given in Figure 2. 

Situation schemata can be adapted to various kinds of semantic interpretation. 
One could give some kind of operational interpretation in a suitable program- 
ming language, exploiting logical insights. But in their present form, situation 
schemata do not go further than being complex attribute- value structures. Sit- 
uations, locations, individuals, and relations constitute the basic domains of the 
structure. Constraints are declarative descriptions of the relationships holding 
between aspects of linguistic form and the semantic representation itself. 

Theoretical issues in natural language semantics have been implemented on 
pilot systems employing situation schemata. The grammar described in [16], for 
example, has been fully implemented using a lexical-functional grammar system 
[17] and a fragment including prepositional phrases has been implemented using 



BABY-SIT is a computational medium based on situations, a prototype of which 
is currently being developed in KFF"^^ (Knowledge Fngineering Fnvironment) 
[20]. The implementation language is Common Lisp and the BABY-SIT desktop 
is based on X Windows running on a SPARCStation (cf. Figure 3). The primary 
motivation underlying BABY-SIT is to facilitate the development and testing of 
programs in domains ranging from linguistics to artificial intelligence in a unified 
framework built upon situation-theoretic constructs [26, 27, 29]. An interactive 
environment helps one to develop and test his program, observe its behavior 
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Figure 2: Situation schema for "Alice saw the cat." 



vis-a-vis extra (or missing) information, and issue queries [26]. 

The computational model underlying the current version of BABY-SIT con- 
sists of nine primitives: individuals^ times, places, relations, polarities, parame- 
ters, infons, situations, and types. Each primitive carries its own internal struc- 
ture. Individuals are unique atomic entities which correspond to real objects 
in the world. Times are individuals of distinguished type, representing tem- 
poral locations and, similar to times, places are individuals which represent 
spatial locations. A relation has argument roles which must be occupied by 
appropriate objects. Infons are the discrete items of information of the form 
<^ rel, argi, . . . , argn, pol where rel is a relation, a^rgi, 1 < z < n, is an 
object of the appropriate type for the zth argument role, and pol is the polarity. 
Parameters are 'place holders' for objects in the model. They are used to refer 
to arbitrary objects of a given type. Types, on the other hand, form higher-order 
uniformities for individuating or discriminating other uniformities in the world. 

Situations are set-theoretic constructs, e.g., a set of parametric infons (com- 
prising relations, parameters, and polarities). A parametric infon is the basic 
computational unit. By defining a hierarchy between them, situations can be 
embedded via the special relation part-of In this way, a situation s can have in- 
formation about another situation s' which is part of s. A distinguished situation 
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Figure 3: The software structure of BABY-SIT. 



called background situation (denoted by w) contains infons which are inherited 
by all situations, i.e., w is implicitly part of all situation structures in the en- 
vironment and its infons hold in all situations. However, situations other than 
w may contain infons that vary from situation to situation. A situation can be 
either (spatially and/or temporally) located or unlocated. Time and place for a 
situation can be declared by time-of and place-of relations, respectively. 

Anchoring of parameters is made possible by anchoring situations which allow 
parameters to be anchored to objects of appropriate types — individuals, situa- 
tions, parameters, etc. But a parameter must be anchored to a unique object in 
an anchoring situation, i.e., it is anchored once in a given anchoring situation. On 
the other hand, more than one parameter may be anchored to the same object 
in an anchoring situation. Anchoring of a parameter can be done via the special 
relation anchor. Restrictions on parameters must be satisfied by w. 

There are three modes of computation in BABY-SIT: assertion mode, con- 
straints^ and query mode. 



5.4.1 Assertion Mode 

This provides an interactive environment in which one can define objects and 
their types. There are nine basic types corresponding to nine primitives: ~IND 
(individuals), ~TIM (times), ~LOC (places), ~REL (relations), ~POL (polari- 
ties), ~INF (infons), ~PAR (parameters), ~SIT (situations), and ~TYP (types). 
For instance, if / is a place, then / is of type ~LOC, and the infon <^of-type^ /, 
~LOC, 1^ is a fact in w. Note that the type of all types is ~TYP. For example, 
the infons <^of-type, ~LOC, ~TYP, 1> and <^of-type, ~TYP, ~TYP, 1> are 
facts in w. The syntax of the assertion mode (cf. [26]) is similar to that in [12]. 
The architecture of Assertion Mode is shown in Figure 4. 

Suppose bob is an individual, and sitl is a situation. Then, these objects 
can be declared as: 

I> bob: ~IND 
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Figure 4: The architecture of Assertion Mode. 



I> sitl: ~SIT 

The definition of relations includes the appropriateness conditions for their 
argument roles. Appropriateness conditions define the domains to which argu- 
ments of a relation belong. Each argument can be declared to be from one or 
more of the primitives above. If we want sees to have two arguments, the former 
being of type individual and the latter being of type situation, we write: 

I> <sees I ~IND, ~SIT> [1] 

The number in square brackets indicates the minimum number of arguments 
that can be used with the relation. Hence, ^sees ,bob , 1^, for example, is 
considered to be a valid (i.e., unsaturated) infon in the system and it is equivalent 
to ^sees ,bob , - , 1^ where "-" is a null object. 

In order for the parameters to be anchored to objects of the appropriate type, 
parameters must be declared to be from only one of the primitives. It is also 
possible to put restrictions on a parameter in the environment. Suppose we want 
to have a parameter E denoting any individual that sees sitl. This can be done 
by asserting: 

I> E = INDl ^ <sees,INDl,sitl,l> 

INDl is a default system parameter of type ~IND. E is considered as an object 
of type ~PAR such that if it is anchored to an object, say obj 1, then obj 1 must 
be of type ~IND and w must support ^sees , obj 1 , sitl , 1^. 
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Anchoring situations are those that support infons having anchor as their 
relations, anchor has two argument roles: one for a parameter and another for an 
object which serves as an anchor for the parameter, with the minimality condition 
2. For example, if it is the case for Bob that w |= ^sees, bob, sitl,l^, then 
an anchoring situation, say anchor 1, can supply an anchoring which anchors 
parameter E to bob: 

anchorl |= ^anchor , E ,bob , 1^ . 

Given an anchoring situation, the anchoring defined by this situation can be 
applied on the propositions asserted to the system in Assertion Mode. Anchoring 
is performed by replacing each occurrence of an anchored parameter by its anchor 
defined in the anchoring situation. For example, giving anchorl as the anchoring 
situation and asserting the proposition 

sitl 1= <man,E,l> 

results in the proposition sitl |= ^man,bob,l^ holding. 

Parametric types are also allowed in BABY-SIT. They are are of the form 
[P I s 1= /] where P is a parameter, s is a situation (i.e., a grouiidiiig' situation), 
and / is a set of infons. The type of all situations that Bob sees can be defined 
in BABY-SIT as follows: 

I> ~SITALL = [SITl I w 1= <sees,bob,SITl,l>] 

Hence, ~SITALL is seen as an object of type ~TYP in BABY-SIT and can 
be used as a type specifier for declaration of new objects in the environment. An 
object of type ~SITALL, say obj2, is an object of basic type ~SIT such that w 
supports the infon ^sees ,bob , obj 2 , 1^. 

Naming infons enables one to easily refer to them in expressions. For instance, 
the infon ^sees , bob, sitl , 1^ can be named infonl: 

I> infonl = ^sees , bob , sitl , 1^ 

In addition to defining situations, one can create hierarchies among situations. 
For example, the following sequence of assertions creates a situation sit 2, de- 
fines it as a subsituation of situation sitl, and at the same time adds the infon 
<blind,bob,0> into it: 

I> sit2: ~SIT 

I> sit2 1= {<make-part-of ,sit2,sitl,l>, <blind,bob,0>} 

This will force sitl to support all the infons supported by sit 2. As a result, 
it will be the case that sitl |= ^part-of , sit2 , sitl , 1^. 

Similar operations can be done via the situation browser as well. The situ- 
ation browser enables one to create situations, browse them graphically, add or 
delete infons, and establish hierarchies among situations. Since all situations are 
required to cohere in BABY-SIT, assertion of propositions that will yield inco- 
herent situations are refused by the system both for assertions of propositions in 
Assertion Mode and for the ones asserted during chaining. 
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Variables in BABY-SIT are solely used in constraints and query expressions, 
and have scope only within the constraint or the query expression they appear. 
A variable can match any object appropriate for the place or the argument role 
it appears in. For example, given the relation above, variables ?S and ?X in the 
proposition ?S|=^sees , ?X, sitl , 1^ can only match objects of type ~SIT and 
~IND, respectively. 

5.4.2 Constraints 

A BABY-SIT constraint is of the form: 

antecedently ■ ■ antecedentn {<=, =>, <=>} 
consequently • • consequent^- 

Each antecedentiy 1 < z < n, and each consequently 1 < j < m, is of the form 
sit {|=, ^} <^rely argiy . . . , argiy pol^ such that rel and each arg^y 1 < ^ < 
can either be an object of the appropriate type or a variable. 

Each constraint has an identifier associated with it and must belong to a 
group of constraints (i.e., a perspectivity set). Eor example, the following is a 
backward-chaining constraint named HUMAN-BEINGS-012 under the constraint 
group SPECIES-PERSPECTIVE: 

SPECIES-PERSPECTIVE: 
HUMAN-BEINGS-012: 

?S 1= <human,?X,l> <= ?S |= <man,?X,l> 

where ?S and ?X are variables. ?S can only be assigned an object of type ~SIT 
while ?X can have values of some type appropriate for the argument roles of the 
human and man relations. This constraint can apply in any situation. Constraints 
can also be situated. Eor example, IIUMAN-BEINGS-012 can be rewritten to apply 
only in situation sitl: 

sitl 1= <human,?X,l> <= sitl |= <man,?X,l>. 

Conditional constraints of BABY-SIT come with a set of background condi- 
tions which must be satisfied for the constraint to apply. Eor example, to state 
that blocks fall if not supported, one can write: 

NATURAL-LAW-PERSPECTIVE: 
FALLING-BLOCK: 

?S1 1= <block,?X,l>, 

?S1 1= <supported,?X,0> => ?S2 |= <falls,?X,l> 
UNDER-CONDITIONS: 
w: ^exists , gravity , 1^. 

Background conditions are assumptions which are required to hold for con- 
straints to be eligible for activation. FALLING-BLOCK can become a candidate 
for activation only if it is the case that w ^ ^exists , gravity ,0^, i.e., if the 
absence of gravity is not known in the background situation. 
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The forward- chaining mechanism of BABY-SIT is initiated either when the 
user tells the system to do so or by assertion of a new object into the system. 
A candidate forward- chaining constraint is activated whenever its antecedent is 
satisfied. All the consequences are asserted if they do not yield a contradiction in 
the situation into which they are asserted. New assertions may in turn activate 
other forward- chaining constraints. Candidate backward-chaining constraints are 
activated either when a query is entered explicitly or is issued by the forward- 
chaining mechanism. Antecedent parts of any constraint are, by default, proved 
by the backward-chaining constraints in the perspectivity set of that constraint. 
However, they may also be proved with respect to the backward-chaining con- 
straints in a given antecedent perspectivity set. 

5.4.3 Query Mode 

Query mode enables one to issue queries about situations. There are several 
possible actions which can be controlled by the user: 

• Providing a perspectivity set to make the query mechanism prove the query 
with respect to the backward chaining constraints in this set. 

• Providing an antecedent perspectivity set to make the query mechanism 
prove the antecedents of the backward chaining constraints with respect to 
the backward chaining constraints in this set. 

• Searching for solutions by using a given group of constraints. 

• Replacing each parameter in the query expression by the corresponding in- 
dividual if there is a possible anchor, either partial or full, for that parameter 
provided by the given anchoring situation. 

• Returning solutions. (Their number is determined by the user.) 

• Displaying a solution with its parameters replaced by the individuals to 
which they are anchored by the given anchoring situation. 

• For each solution, displaying infons anchoring any parameter in the solution 
to an individual in the given anchoring situation. 

• Displaying a trace of anchoring of parameters in each solution. 

The computation upon issuing a query is done either by direct querying 
through situations or by the application of backward-chaining constraints. A 
situation, s, supports an infon if the infon is either explicitly asserted to hold in 
s, or it is supported by a situation s' which is part of s, or it can be proven to 
hold by application of backward-chaining constraints. Assume the following: 

sitl 1= {^sees ,E, sit2 , 1^ , ^part-of , sit2 , sitl , 1^} 

sit2 1= <time-of ,sit2,t2,l> 

w 1= ^sees , bob , sitl , 1^ 
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Given anchoring situation anchor 1, a query and the system's response to it 
are as follows: 

Q> ?s 1= {<sees,E,?Y,l>, <time-of , sit2 , ?Z , 1>} , 
?S ^ <blind,bob,l> 

Solution 1: 

sitl 1= {^sees ,bob , sit2 , 1^ , ^time-of , sit2 ,t2 , 1^} , 
sitl ^ <blind,bob,l> 

with the anchoring: 

anchorl |= ^anchor , E ,bob , 1^. 

5.5 Critique of PROSIT and ASTL 

A tableau comparison of PROSIT, ASTL, and BABY-SIT is given in Table 1. 

5.5.1 Types 

At the heart of situation theory lies a scheme of individuation. Situations, rela- 
tions, individuals, temporal locations, and spatial locations are the basic unifor- 
mities. The need for a mathematical representation of these uniformities resulted 
in what is known as types. Types are higher-order uniformities which cut across 
basic uniformities. The ontology of situation theory has been extended further to 
include other uniformities such as infons, polarities, etc. In this respect, PROSIT 
and ASTL do not allow their objects to be of some type. Only situations can be 
declared to have a situation type. Other objects in the system are left untyped. 
This approach has particular consequences on the conception of relations and 
parameters which are explained in the sequel. 

5.5.2 Parameters 

The development of types necessitates devices, such as parameters, for making 
reference to arbitrary objects of a given type. In ASTL, there is no special 
treatment of parameters which are just atomic objects in the model. Declaring 
situations to be of some type allows abstraction over situations to some degree. 
But, the actual means of abstraction over objects in situation theory, viz. pa- 
rameters, does not carry much significance in ASTL. Parameters are only used in 
identifying situation types. Since there is no notion of types other than situation 
types in ASTL, a parameter can hold the place of any object. PROSIT treats 
parameters in a way similar to its variables, except they can be equated to any 
constant or parameter. PROSIT has no mechanism to define types. It cannot 
define a situation-type explicitly. On the other hand PROSIT can query a certain 
type of situation and put constraints between situation-types. 
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Constraint Type 


PROSIT 


ASTL 


BABY-SIT 


Nomic 




V 


V 


Necessary 


V 


V 


V 


Conditional 






V 


Situated 


V 




V 


Global 




V 


V 



Constraint Class 


PROSIT 


ASTL 


BABY-SIT 


Situation constraint 




V 


V 


Infon constraint 


V 


V 


V 


Argument constraint 






V 



Computational Feature 


PROSIT 


ASTL 


BABY-SIT 


Unification 




V 


V 


Type-theoretic 






V 


Coherence 






V 


Forward- chaining 


V 




V 


B ackwar d- chaining 


V 


V 


V 


Bidirectional-chaining 


V 




V 




Miscellaneous Features 


PROSIT 


ASTL 


BABY-SIT 


Circularity 




V 


V 


Partiality 


V 


V 


V 


Parameters 


? 


? 


V 


Type Abstraction 


? 


? 


V 


Parameter restriction 




? 


V 


Anchoring 


? 


? 


V 


Information nesting 


V 


V 


V 


Unsaturated infons 


? 




V 


Nonmonotonic reasoning 






V 


Set operations 


V 







Legend: ^y : exists, -: doesn't exist, 

? : partially/conceptually exists. 



Table I: Tableau comparison of existing approaches. 
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It is useful to have parameters that range over various classes rather than to 
work with parameters ranging over all objects. Such particularized parameters 
can be obtained by parameter restriction. On the other hand, in situation theory, 
parameters are used to achieve abstraction at the level of almost all object types, 
i.e., situations, individuals, temporal locations, etc. by using type abstraction. 

In PROSIT some of these are hard to achieve. First of all, there is no typing 
in PROSIT. A variable can match any parameter or constant without due regard 
to types. Obtaining restricted parameters and type abstraction is not possible 
since there is no built-in mechanism in the system. But one can pose queries 
on restricted parameters. For example, all men kicking footballs can be queried 
using the following expression: 

(AND (kicking *a *b) (man *a) (football *b)). 

Although none of the variables are restricted, the expression queries a re- 
stricted class of individuals. 

In ASTL, abstraction is only at the level of situations. There is no direct 
equivalent of properties in ASTL. Consider the abstraction for an individual hav- 
ing the property of being happy in some situation s: 

[X \s\= <.happy, X, 1>]. 

In ASTL, Black achieves this by allowing situation types with parametric 
infons. But this is not an appropriate way to use abstractions since one cannot 
abstract over other objects such as individuals, temporal locations, etc. (cf. 
object type-abstraction and situation type-abstraction in [12]). 

5.5.3 Parameter Anchoring 

Parameters are place holders for indeterminate objects in situation theory and 
yield a form of abstraction over objects. The ties of these abstractions with the 
real world occur via a kind of assignment function called anchor. This function 
changes from one cognitive agent to another, and from one perspective to another 
of a single cognitive agent. Information content of an abstract object increases 
when its parameters are anchored to objects in the real world by an anchor. An 
anchor maps a parameter to a unique, appropriate object in the world. Tech- 
nically speaking, a parameter must be anchored to an object of the same type 
since the parameter is a filler for an object having specific properties. The issues 
of anchoring to a unique object and anchoring to an object of the same type 
introduce technical difficulties in building a computational system. 

Some treatment of parameters is given in PROSIT with respect to anchoring. 
Given a parameter denoting an object of some type (individual, situation, etc.), 
an anchor is a function which assigns an object of the same type to the parameter 
[12, pp. 52-63]. Hence, parameters work by placing restrictions on anchors. But, 
there is no appropriate anchoring mechanism in PROSIT since its parameters are 
untyped. 
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In the case of ASTL, there are several points worth mentioning. Black pro- 
poses to consider anchors as situations [anchoring situations) having infons of 
the form <^ancbor-to^ iabei, term^ and other related infons. Second, the cur- 
rent version of ASTL must be modified to use anchoring situations. This cannot 
be controlled by the user. The main reason is that whenever an anchoring occurs, 
the system must check whether the first argument of the relation ancbor-to is a 
label and the second one is a term. Moreover, the system must assure that the pa- 
rameter is anchored to only one object in that anchoring situation. Finally, type 
checking for both of the arguments is required. The crux of all these problems 
lies in ASTL's not having type-theoretic objects and not employing parameters 
as they are intended in situation theory. 

5.5.4 Infons 

There are three characteristics of an infon in the existing systems which should be 
evaluated from the standpoint of situation theory: argument places^ minimality 
conditions^ and argument roles. 

Each relation should have a limited number of argument places. Consider the 
relation walks. A reasonable assumption is that this relation has four argument 
places: a walking agent, a direction/destination, the location of walking, and the 
time of walking. 

To have a formally well-defined infon, there must be a lower bound as to the 
number of argument places to be filled in an n-place relation. For example, at 
least one argument place of the relation walks is to be filled, namely the walking 
agent. Otherwise, the infon <^walks^ would have zero information content. 
Minimality conditions are, then, necessary for a relation to provide an item of 
information. All argument places of a relation in ASTL are required to be filled, 
and consequently all infons are saturated. As for the infons in PROSIT, there is 
no restriction as to the number of argument roles of a relation to be filled. 

Any object appearing as an argument of a relation must be appropriate for 
the argument role imposed by that argument place. Hence, appropriateness con- 
ditions must be defined for each possible argument place of a relation. This is 
generally done by forming a set of infons for an argument place which are sup- 
posed to be supported by the world situation for a given object. At the primary 
level, each argument role requires the appropriate object to be of some basic 
type. That is, each argument role is associated with a certain type, the type of 
the object that may legitimately fill that argument role. In a technical sense, 
appropriate conditions for an argument role are complex types having possibly 
the world situation as their grounding situation. 

PROSIT and ASTL do not allow definition of appropriateness conditions for 
arguments of relations, mainly because objects are not typed in these systems. 
However, one can define restrictions on the parameters of infons by using re- 
stricted infons in PROSIT. The relation walks^ for example, might require its 
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walking agent role to be filled by an animate object. Such a restriction can be 
defined only by using constraints in PROSIT and ASTL. However, this requires 
writing the restriction each time a new constraint about walks is to be added. 
Having appropriateness conditions as a built-in feature would be better. 

5.5.5 Hierarchy of Situations 

Being in a larger situation gives one the ability of having information about its 
subsituations. Although there is no mention of hierarchy in situation theory, the 
part-of relation can be used to build such a structure (i.e., information nesting) 
among abstract situations. ASTL does not have a mechanism to relate two situ- 
ations so that one will directly support all the facts that the other does. While 
this might be achieved via constraints in ASTL, there is no built-in structure 
between situations. 

PROSIT has a tree structure among situations established by the use of owner 
and subchunk relations. In fact, this hierarchy of PROSIT turns out to be useful 
in problems regarding knowledge and belief. 

The other two PROSIT relations (subtype and subsituation) should be ex- 
amined carefully. At first glance, it seems that there is a similarity between 
these relations and the concept of inheritance in object-oriented programming. 
However, in PROSIT the supersituation inherits all the infons from the subsitua- 
tion, whereas in object-oriented programming it is the subclass that inherits the 
properties and methods from the superclass. 

Another question may come as to where one can use these relations. The 
example given in the PROSIT manual uses these relations to classify the airplanes 
of type DC (DC-9, DC-10, and so on). But from the situation-theoretic point 
of view, it is not correct to consider airplanes of type DC as a situation. An 
agent does not individuate DC type of airplanes as a situation and DC-9s as a 
subsituation of that situation. These can only be considered as a class and its 
subclass. This example is surely well suited to object-oriented programming, but 
not to situation theory. 

5.5.6 Coherence of Situations 

ASTL does not provide a mechanism, such as truth maintenance, to preserve 
coherence within situations. This is left to the user's control and can be achieved 
by specifying some special constraints in the ASTL descriptions. A constraint of 
the form 

*S: [S I S 1= (actual, S,0)] -> *S: [S | S |= (*R,*A,l)], 

*S: [S I S 1= (*R,*A,0)] 

is given by Black as an example. However, this is not a solution to the problem 
of having incoherent situations. Moreover, this approach may be quite expensive 
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for the user since maintaining coherence is a comphcated task and when left to 
the user, a large number of constraints must be written. What is worse is that 
consequences of allowing incoherent situations and reasoning over them may be 
drastic, e.g., it may lead to unintended models during computation. It seems that 
coherence, as a built-in notion, can hardly be embedded in an extension of the 
existing version of ASTL since it is not a syntactical matter and requires meta 
level control over the whole system. 

Similar to ASTL, PROSIT cares little about coherence within situations. This 
is left to the user's control. 

5.5.7 Constraints 

PROSIT supports the concept of constraints, but handles them in a different 
fashion. These come in three flavors in PROSIT: forward- chaining constraints, 
backward-chaining constraints, and forward- and backward-chaining constraints 
(bidirectional-chaining constraints). In fact, both methods (forward or backward) 
result in the same answers to queries. However, forward- chaining incurs a high 
cost at assertion-time, and backward-chaining incurs a high cost at query-time. 

ASTL constraints are all in the form of backward-chaining constraints. The 
user can only issue queries. However, an intelligent agent has the ability to 
not only acquire information about situations and obtain new information about 
them by being attuned to assorted constraints, but also act accordingly to alter its 
environment. Thus, having forward- chaining constraints as well would be better. 
In this way, new situations would be created, new infons would be inserted into 
situations, and consequences of new infons would be observed. 

PROSIT's constraints are situated infon constraints, i.e., they are about local 
facts within a situation rather than about situation-types. Still, it is possible to 
simulate constraints that are not local to one situation (but are global). This can 
be achieved by introducing a situation which is global to all other situations and 
then asserting the constraint in this global situation. Because all other situations 
will be in this global situation, any constraint that is asserted here will apply to 
all situations. For example, 

( ! = (resp topsit 
(<= (!= *Sitl (touching *X *Y)) 

(!= *Sitl (kissing *x *Y))))) 

states that if, in situation topsit, there is a situation that supports a fact with 
the relation kissing^ then that situation also supports a fact with the relation 
touching on the same arguments. 

Situated constraints offer an elegant solution to the treatment of conditional 
constraints which apply in situations that obey some condition. For example, 
when Alice throws a basketball, she knows it will come down — a constraint to 
which she is attuned, but which would fail if she tried to play basketball in a 
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space shuttle. This is actually achieved in PROSIT since information is specified 
in the constraint itself. Situating a constraint means that it may only apply to 
appropriate situations. This is a good strategy to achieve background conditions. 
However, it might be required that conditions set not only within the same sit- 
uation, but also between various types of situations. Because constraints have 
to be situated in PROSIT, not all situations of the appropriate type will have a 
constraint to apply. 

Although one can define constraints between situations in ASTL, the notion 
of background conditions for constraints is not available. This means that condi- 
tional constraints are not available. However, this can be achieved by writing a 
set of conditions which must be satisfied for the constraint to qualify as an appli- 
cable one. These conditions will obviously be placed on the consequent part of 
each ASTL constraint since all ASTL constraints are used for backward-chaining. 

Black identifies three classes of constraints in [8]: 

• Situation constraints: Constraints between situation types. 

• Infon constraints: Constraints between infons (of a situation). 

• Argument constraints: Constraints on argument roles (of an infon). 

Only PROSIT cannot model situation constraints since it does not have sit- 
uation types. Defining infon constraints is possible in all systems. However, 
argument constraints are a built-in feature only in BABY-SIT since they directly 
correspond to having appropriateness conditions for argument roles of relations 
in infons. 

5.5.8 Nonmonotonicity 

A typical user studying situation theory will not only want to investigate if an 
infon is supported by a situation, but also want to see if an infon is not supported 
by that situation. In other words, he would like to know if a situation is not of a 
certain type and then use this knowledge. This calls for negation in both query 
statements and constraints. A straightforward way to do this is by having the 
appropriate syntax and semantics for the negation of supports relation, i.e., by 
letting be used in these statements. Consider the BABY-SIT constraint: 

?S 1= <paid-little,?W,?S,l>, 

?S ^ <has-other-income,?W,?S,l> <= ?S |= <poor,?W,l> 

which expresses the rule of reasoning "a worker is poor if he is paid little, under 
the assumption that he has no other income." 

Having such a construct in the constraint mechanism, and hence in the query 
mechanism, allows nonmonotonic reasoning. Unfortunately, neither PROSIT nor 
ASTL have an equivalent construct. 
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5.5.9 Some Formal Properties 



Black shows that ASTL is sound, but he leaves its completeness formally un- 
proved. Similar arguments are valid for PROSIT as well. Although it has not 
been proved explicitly, PROSIT can be said to be a sound system. BABY-SIT 
is, on the other hand, a sound and complete system. BABY-SIT is based on 
the constructs and the inference mechanism of KEE. The situation structures are 
developed upon the KEE's world system based on Morris and Nado's work [21]. 
The inference mechanism of the BABY-SIT is the same as that of KEE, except 
for the chaining control mechanism, and BABY-SIT constraints form a subset of 
the action rules that can be defined in KEE. 

5.5.10 Domains of Application 

The main group of problems that PROSIT can handle is that of individual knowl- 
edge and belief in multi-agent systems, and common knowledge (mutual informa- 
tion). There are three main properties that enable PROSIT to simulate human- 
like reasoning. The first one is situated programming, i.e., infons and constraints 
are local to situations. The second is PROSIT's situation tree structure, which 
one can use to represent nested knowledge/belief. The third is the use of incon- 
sistencies to generate new information. Self- referential expressions and situations 
as arguments of infons are two powerful features. These features can efficiently 
be used in representing knowledge and belief. The owner relation and the super- 
chunk relation are useful in modeling epistemic puzzles [14]. 

ASTL has been developed with natural language processing in mind. Still, it is 
possible to use it as a general knowledge representation language. The advantages 
of employing declarative or procedural approaches in knowledge-based systems 
are still being debated. Both have been justified from perspectives of cognitive 
science and philosophy. Eor the time being, the declarative approach fits best 
for a situation-theoretic computational language, but one can also benefit from 
procedural knowledge. PROSIT is a candidate for a unified framework since it is 
possible to use Lisp statements as part of the language. 

BABY-SIT is being developed as a general-purpose programming environ- 
ment, specifically adopting the ontological features of situation theory and putting 
them into the comfortable reach of the user. Its interactive nature and facilities 
to organize and keep track of information qualifies it as a general knowledge rep- 
resentation system. The fiexibility of situation semantics as a powerful linguistic 
account to handle various linguistic phenomena has led to the initiation of a pre- 
liminary study towards employing BABY-SIT in the resolution of pronominal 
anaphora [30, 31]. 
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5.5.11 User Interfaces 

PROSIT and ASTL provide simple user interlaces. The user writes definitions 
into a file which can be loaded in a Common Lisp environment. Other than 
querying what situations support, the user has the opportunity to view some 
system leatures. ASTL is not an interactive language in the sense that a static 
definition is input to the system and the user can only observe what can be 
inferred from these definitions. Moreover, one cannot assert propositions to the 
system; new propositions must first be added to the static description and then 
the system must be reloaded. This prevents the user from directly seeing the 
consequences of his propositions. 

6 Concluding Remarks 

Serious thinking about the computational aspects of situation theory is just 
starting. There have been some proposals [8, 9, 16, 26] in this direction, with 
varying degrees of divergence from the ontology of situation theory. ASTL [8] 
and PROSIT [9] mainly offer a Prolog- or Lisp-like programming language while 
BABY-SIT [26, 32] provides a programming environment incorporating situation- 
theoretic constructs. 

We believe that computational aspects of situation theory call for deeper in- 
vestigation. Although the current attempts are in their infancy, they already 
have some applicability in artificial intelligence and natural language processing. 
However, their use should be further demonstrated to show why situation theory 
provides a challenging arena for studying various phenomena in these fields. 
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